Adding a Policy Studio Rule for Users Credentials Information
The SBC can function as authentication server for SIP messages requests. The SBC is used to store the users (SIP phones) credentials information. Irrespective of under which local SBC in the network the phone is located, the ARM provides a centralized point for global credentials management of all SIP phones in a network. The SBC requests the ARM to provide credentials for specific users. This information is stored in the ARM users database. When the SBC needs to authenticate a user, it sends a REST request to the ARM to obtain the credentials for that user and then sends the ‘challenge’ for credentials back to the client. The client then resends the request with an Authorization header (containing a response to the ‘challenge’) and the authentication process continues regularly. Request for authentication is relevant for INVITE and for REGISTER requests coming from a SIP phone. The following figures show the flows:
Request for Authentication: Invite Sequence
Request for Authentication: Register Sequence
To configure the SBC to send the above REST API to the ARM, you need to configure an IP Group with specific settings in the SBC's Web interface. For more information, see Configuring the SBC to Send the REST API.
The operator should prepare credentials information to be provided to the SBC upon credentials requests. The information should be part of the ARM users database. The operator must define a dedicated dictionary attribute where the credentials will be stored for each authorized SIP phone. The information is provided by the ARM using the Policy Studio matching feature. Policy Studio is divided into two types of rules: (1) Policy Studio Rules designated for Routing and (2) Policy Studio Rules designated for Credentials. The operator who does not source ARM credentials information does not need to define Credentials Policy rules and can use the regular functionality of Policy Studio for Calls and Registrations pre-routing smart manipulations.
| ➢ | To add a Policy Studio rule for credentials information: |
| 1. | Add a rule and select Credentials from the rule’s ‘Type’ drop-down. The newly created rule will automatically be placed in the ‘Credentials’ section in the Policy Studio screen to distinguish it from Routing related rules. |
Credentials
| 2. | The matching criteria for Policy Studio of type Credentials must be User_URI and (optionally) HOST_URI. This information is used as a unique identifier to find the correct entry in the Users page to retrieve requested credentials information. |
These are the only properties that can be used for matching of the credentials request.
| 3. | Optionally apply the following matching criteria to narrow the group of users to whom this service (of supplying credentials by the ARM) is provided: |
| ● | Source Node |
| ● | Source Peer Connection |
| ● | Source Resources group |
| ● | Source users group |
Add Policy Studio Rule - Type 'Credentials'
If the ARM does not find in the users database a match for a specific URI_USER and (optional) URI_HOST, it will return a 404 (not found) HTTP response to the SBC (and consequentially, to the SIP phone). If you want to have a configuration in which every user (SIP phone) is allowed to register only upon specific conditions (for example, only from certain IP Group/Peer Connection or Group of Peer Connections or Nodes, etc.), it can be done by a combination of Match (condition) part of the Credential Policy Studio rule and a specific action named Discard_Credentials relevant for credentials rules only. In this case, although the user is found but is not authorized for the specified IP group or SBC, the ARM will respond with a 403 HTTP response (forbidden).
For example, the following rule of type Credentials named DiscardUnauthorizedCredentialRequests will not provide credentials for a request coming from node ‘China’ for users who are part of the ‘United States’ users group; the ARM will respond with a 403 HTTP response (forbidden).
The order (priority) of the rules in Policy Studio is important. For example, if an operator added ‘Discard Credentials’ but there is a higher rule with the same match criteria, all users in the ‘Discard Credentials’ rule will be authorized (the higher rule will be applied).